internal/executor/middleware_route_match.go-36-36 (1)

36-36: ⚠️ Potential issue | 🟡 Minor

原始路由匹配错误被丢弃，丢失了诊断上下文。

router.Match 返回的 err 可能包含具体的失败原因（如权限不足、模型不匹配等），但第 36 行用通用的 "no routes available" 消息替换了它。建议在错误消息中保留原始错误信息：

-		err = domain.NewProxyErrorWithMessage(domain.ErrNoRoutes, false, "no routes available")
+		err = domain.NewProxyErrorWithMessage(domain.ErrNoRoutes, false, "no routes available: "+err.Error())

internal/adapter/provider/antigravity/request.go-272-300 (1)

272-300: ⚠️ Potential issue | 🟡 Minor

finalizeOpenAIWrappedRequest 中多个 sjson.SetBytes 错误被静默忽略。

Lines 284-294 连续调用了 8 次 sjson.SetBytes / sjson.DeleteBytes，所有错误均用 _ 丢弃。如果中间某次操作失败（例如无效 JSON），后续操作将基于损坏的 payload 继续执行，产出不可预期的结果。

建议至少对关键字段（如 project、model）检查错误，或在整体失败时返回原始 payload。

internal/adapter/provider/antigravity/translator_helpers.go-1-4 (1)

1-4: ⚠️ Potential issue | 🟡 Minor

包注释与实际包名不一致。

注释写的是 Package util，但实际包名是 antigravity。

🔧 建议修复

-// Package util provides utility functions for the CLI Proxy API server.
-// It includes helper functions for JSON manipulation, proxy configuration,
-// and other common operations used across the application.
-package antigravity
+// Package antigravity provides the Antigravity provider adapter,
+// including helpers for JSON manipulation and request/response transformation.
+package antigravity

internal/adapter/provider/antigravity/translator_helpers.go-90-97 (1)

90-97: ⚠️ Potential issue | 🟡 Minor

DeleteKey 静默忽略删除错误，且多次删除后路径可能失效。

Walk 预先收集所有路径，但每次 sjson.Delete 会改变 JSON 结构，可能导致后续路径指向错误位置（尤其是数组索引场景）。建议从后往前删除（逆序遍历 paths），减少路径偏移问题，并至少记录删除错误。

🔧 逆序删除建议

 func DeleteKey(jsonStr, keyName string) string {
 	paths := make([]string, 0)
 	Walk(gjson.Parse(jsonStr), "", keyName, &paths)
-	for _, p := range paths {
+	for i := len(paths) - 1; i >= 0; i-- {
+		p := paths[i]
 		jsonStr, _ = sjson.Delete(jsonStr, p)
 	}
 	return jsonStr
 }

internal/adapter/provider/antigravity/schema_cleaner.go-1-2 (1)

1-2: ⚠️ Potential issue | 🟡 Minor

包注释与实际包名不匹配。

注释写的是 "Package util provides utility functions for the CLI Proxy API server."，但实际包名是 antigravity。

🐛 修复建议

-// Package util provides utility functions for the CLI Proxy API server.
-package antigravity
+// Package antigravity provides Antigravity provider adapter and utilities.
+package antigravity

internal/executor/middleware_dispatch.go-54-84 (1)

54-84: ⚠️ Potential issue | 🟡 Minor

缩进严重不一致，影响代码可读性和可维护性。

Lines 55-84 的缩进层级混乱，嵌套块的 tab 数量不一致。例如：

• Line 55 的 if e.converter.NeedConvert 比周围代码多了一级缩进
• Line 62 的 if currentClientType == domain.ClientTypeCodex 缩进级别与预期不符
• Line 77 的 convertedURI 赋值缩进回退

虽然 Go 编译器会验证大括号配对，但这种缩进会误导代码审查者对逻辑嵌套的理解。建议使用 gofmt 或 goimports 重新格式化此段代码。

internal/converter/codex_to_openai.go-376-403 (1)

376-403: ⚠️ Potential issue | 🟡 Minor

删除未使用的函数 extractCodexOutputText。

该函数在整个代码库中未被调用，属于死代码。

internal/converter/openai_to_codex.go-414-414 (1)

414-414: ⚠️ Potential issue | 🟡 Minor

state.Custom 类型断言缺少安全检查

第 414 行 st := state.Custom.(*openaiToResponsesState) 是裸类型断言。如果 state.Custom 被其他代码意外设置为不同类型，运行时会 panic。建议使用带 ok 检查的断言（与 getClaudeStreamState 中的做法保持一致）。

建议的改动

-	st := state.Custom.(*openaiToResponsesState)
+	st, ok := state.Custom.(*openaiToResponsesState)
+	if !ok {
+		st = &openaiToResponsesState{ /* ... 初始化字段 ... */ }
+		state.Custom = st
+	}

internal/converter/openai_to_codex.go-80-80 (1)

80-80: ⚠️ Potential issue | 🟡 Minor

变量 c 遮蔽了方法接收者

第 80 行 c := m.Get("content") 中的局部变量 c 遮蔽了第 23 行的方法接收者 c *openaiToCodexRequest。虽然接收者在此处未再使用，但这降低了可读性且容易引入隐患。建议重命名为 contentVal 或其他不冲突的名称。

建议的改动

-			c := m.Get("content")
-			if c.Exists() && c.Type == gjson.String && c.String() != "" {
+			contentVal := m.Get("content")
+			if contentVal.Exists() && contentVal.Type == gjson.String && contentVal.String() != "" {
 				partType := "input_text"
 				if role == "assistant" {
 					partType = "output_text"
@@ ...
-			} else if c.Exists() && c.IsArray() {
-				for _, it := range c.Array() {
+			} else if contentVal.Exists() && contentVal.IsArray() {
+				for _, it := range contentVal.Array() {

web/src/pages/providers/components/clients-config-section.tsx (1)

173-186: Strict Mode 区域布局重构，整体结构合理。

布局从之前的结构改为 flex 行排列，左侧放标签和描述，右侧放开关，语义清晰。

小建议：items-center 在描述文字较长换行时，Switch 会相对整个左侧 div 垂直居中，可能导致开关与标签文字不对齐。如果描述可能换行，可考虑使用 items-start 并给 Switch 加少量上边距以保持与标签对齐。不过如果描述始终较短，当前实现没有问题。

web/src/hooks/queries/use-providers.ts (2)

54-63: 获取-合并策略：data as Provider 回退分支实际不可达

getTransport().getProvider(id) 在 provider 不存在时会抛异常（网络错误 / 404），不会返回 undefined。因此 Line 61 的 existing ? 三元表达式中 falsy 分支 (data as Provider) 在实际运行中永远不会被执行。这不是功能性 Bug，但会误导后续读者以为存在「无现有数据时仅用 partial data 发请求」的合法路径。

建议简化逻辑，移除不可达分支：

♻️ 建议的简化写法

     mutationFn: async ({ id, data }: { id: number; data: Partial<Provider> }) => {
       const existing =
         queryClient.getQueryData<Provider>(providerKeys.detail(id)) ||
         queryClient
           .getQueryData<Provider[]>(providerKeys.list())
           ?.find((provider) => provider.id === id) ||
         (await getTransport().getProvider(id));
-      const payload = existing ? { ...existing, ...data } : (data as Provider);
+      const payload = { ...existing, ...data };
       return getTransport().updateProvider(id, payload);
     },

---

55-60: 潜在的竞态与陈旧数据风险

此处优先从查询缓存读取现有 provider 数据再与 data 浅合并。需注意两点：

1. 缓存陈旧：如果缓存数据已过期但尚未被 refetch，合并后会把陈旧的字段值发送到后端，可能覆盖其他来源的更新。在多标签页或多人协作场景下尤为明显。
2. 浅合并语义：{ ...existing, ...data } 对嵌套对象（如 config）是整体替换而非深度合并。调用方在更新 config 时需确保传入完整的 config 对象，否则会丢失未包含的字段。

如果后端已从 PATCH（部分更新）切换为 PUT（全量替换）语义，这个 fetch-then-merge 方案是合理的，但建议在函数或模块顶部添加注释说明这一设计决策，帮助后续维护者理解为何需要先获取再合并。

internal/converter/gemini_to_openai.go (3)

296-301: time.Parse 失败时 createdAt 静默为 0，依赖后续 time.Now() 兜底——逻辑正确但缺乏可观测性。

当 createTime 字段存在但格式不符合 time.RFC3339Nano 时，解析错误被静默吞掉，createdAt 保持为 0，后续各 chunk 仍使用 time.Now().Unix()。功能上没问题，但建议至少加一行 debug 日志以便排查时间戳异常。

---

306-319: 重复的 chunk 构造 + createdAt 覆盖模式出现了 7 次，建议提取辅助函数。

每次构造 OpenAIStreamChunk 都重复设置 ID、Object、Created、Model，然后紧跟一个 if createdAt > 0 的覆盖逻辑。可以提取一个小型工厂函数来消除重复：

♻️ 提取辅助函数示例

func newOpenAIStreamChunk(messageID, model string, createdAt int64, choices []OpenAIChoice) OpenAIStreamChunk {
	created := time.Now().Unix()
	if createdAt > 0 {
		created = createdAt
	}
	return OpenAIStreamChunk{
		ID:      messageID,
		Object:  "chat.completion.chunk",
		Created: created,
		Model:   model,
		Choices: choices,
	}
}

然后各处构造可简化为一行调用，例如：

openaiChunk := newOpenAIStreamChunk(state.MessageID, streamMeta.Model, createdAt, []OpenAIChoice{{
	Index: 0,
	Delta: &OpenAIMessage{Role: "assistant", Content: part.Text},
}})

Also applies to: 326-339, 343-356, 359-378, 385-405, 416-429

---

275-280: 将已有的结构体字段转换移至解析后的 geminiChunk 使用，避免重复解析。

第 272 行已通过 json.Unmarshal 将 event.Data 反序列化到 geminiChunk（GeminiStreamChunk 结构体），该结构体已包含 ModelVersion 和 ResponseID 字段。第 275 行的 gjson.ParseBytes 对同一份数据进行重复解析，用来提取这两个字段的值不必要。建议直接使用 geminiChunk.ModelVersion 和 geminiChunk.ResponseID，避免对同一数据的二次解析。

（createTime 的提取可保留，因为需要特殊的 RFC3339Nano 解析和 Unix 时间戳转换）

internal/executor/middleware_route_match.go (1)

27-57: 两个错误分支高度重复，建议提取为辅助函数。

第 27-41 行（router.Match 返回错误）和第 43-57 行（路由列表为空）的处理逻辑几乎完全相同，仅错误消息不同。可以提取为一个私有辅助方法来消除重复。

另外，第 36 行丢弃了 router.Match 返回的原始错误 err，而是创建了新的 ErrNoRoutes 包装。建议使用 fmt.Errorf 保留原始错误上下文，便于问题排查：

♻️ 建议的重构方案

+func (e *Executor) failRouteMatch(c *flow.Ctx, state *execState, msg string, cause error) {
+	proxyReq := state.proxyReq
+	proxyReq.Status = "FAILED"
+	proxyReq.Error = msg
+	proxyReq.EndTime = time.Now()
+	proxyReq.Duration = proxyReq.EndTime.Sub(proxyReq.StartTime)
+	_ = e.proxyRequestRepo.Update(proxyReq)
+	if e.broadcaster != nil {
+		e.broadcaster.BroadcastProxyRequest(proxyReq)
+	}
+	err := domain.NewProxyErrorWithMessage(domain.ErrNoRoutes, false, msg)
+	state.lastErr = err
+	c.Err = err
+	c.Abort()
+}

然后在 routeMatch 中复用：

 	if err != nil {
-		proxyReq.Status = "FAILED"
-		proxyReq.Error = "no routes available"
-		...
-		c.Abort()
-		return
+		e.failRouteMatch(c, state, "no routes available: "+err.Error(), err)
+		return
 	}
 
 	if len(routes) == 0 {
-		proxyReq.Status = "FAILED"
-		proxyReq.Error = "no routes configured"
-		...
-		c.Abort()
-		return
+		e.failRouteMatch(c, state, "no routes configured", nil)
+		return
 	}

internal/converter/tool_name.go (2)

14-22: mcp__ 前缀的 LastIndex("__") 在仅有一个 __ 分隔符时会产生无效缩短。

当名称为 "mcp__very_long_tool_name_..." 且只包含一个 __ 时，LastIndex("__") 返回 3（即 mcp 后的 __），此时 candidate = "mcp__" + name[5:] 等同于原始名称，最终走到第 18-19 行的截断逻辑。

虽然结果仍然正确（截断到 64 字符），但这意味着 mcp__ 特殊处理在单层命名时并没有实际效果，只有在存在多层 __ 分隔（如 mcp__server__tool）时才真正发挥作用。如果这是预期行为，建议添加注释说明。

---

48-67: makeUnique 中的无限循环在实际场景中安全，但可考虑添加上限保护。

for i := 1; ; i++ 理论上是无限循环。虽然在实际使用中工具名称数量有限，不会产生问题，但作为防御性编码，可以考虑添加合理的上限（如 10000）并在超出时 panic 或返回错误，避免极端情况下的挂起。

internal/adapter/provider/antigravity/translator_helpers.go (1)

30-48: strings.NewReplacer 在每次 ForEach 回调中重复创建。

keyReplacer 的替换规则是固定的，可以提取为包级变量，避免在递归遍历大型 JSON 时的重复分配。

♻️ 建议提取为包级变量

+var keyReplacer = strings.NewReplacer(".", "\\.", "*", "\\*", "?", "\\?")
+
 func Walk(value gjson.Result, path, field string, paths *[]string) {
 	switch value.Type {
 	case gjson.JSON:
 		value.ForEach(func(key, val gjson.Result) bool {
 			var childPath string
-			var keyReplacer = strings.NewReplacer(".", "\\.", "*", "\\*", "?", "\\?")
 			safeKey := keyReplacer.Replace(key.String())

internal/flow/engine.go (1)

34-47: Ctx 结构设计合理，但 StreamBody 的生命周期管理需调用方负责。

StreamBody io.ReadCloser 在 Ctx 中没有自动清理机制。确保所有使用 StreamBody 的中间件在完成后正确调用 Close()，避免资源泄漏。

internal/adapter/provider/antigravity/request.go (2)

33-40: isStreamRequest 和 extractSessionID 可用 gjson 替代完整反序列化。

这两个函数各自 json.Unmarshal 完整请求体，仅为读取一个字段。项目已引入 gjson，可直接使用 gjson.GetBytes(body, "stream") 和 gjson.GetBytes(body, "metadata.user_id") 避免不必要的完整解析开销。

♻️ 使用 gjson 的简化示例

 func isStreamRequest(body []byte) bool {
-	var req map[string]interface{}
-	if err := json.Unmarshal(body, &req); err != nil {
-		return false
-	}
-	stream, _ := req["stream"].(bool)
-	return stream
+	return gjson.GetBytes(body, "stream").Bool()
 }
 
 func extractSessionID(body []byte) string {
-	var req map[string]interface{}
-	if err := json.Unmarshal(body, &req); err != nil {
-		return ""
-	}
-	metadata, ok := req["metadata"].(map[string]interface{})
-	if !ok {
-		return ""
-	}
-	userID, _ := metadata["user_id"].(string)
-	return userID
+	return gjson.GetBytes(body, "metadata.user_id").String()
 }

Also applies to: 44-57

---

304-315: applyAntigravityRequestTuning 中 parametersJsonSchema 重命名路径计算依赖字符串切割。

Line 312 使用 p[:len(p)-len("parametersJsonSchema")]+"parameters" 假设路径一定以 parametersJsonSchema 结尾。虽然 Walk 的搜索逻辑保证了这一点，但建议用 strings.TrimSuffix 使意图更明确，且增加防御性。

♻️ 使用 strings.TrimSuffix

 	for _, p := range paths {
-		if renamed, err := RenameKey(strJSON, p, p[:len(p)-len("parametersJsonSchema")]+"parameters"); err == nil {
+		if renamed, err := RenameKey(strJSON, p, strings.TrimSuffix(p, "parametersJsonSchema")+"parameters"); err == nil {
 			strJSON = renamed

internal/adapter/provider/antigravity/request_test.go (1)

9-44: 测试覆盖了 Claude 模型的核心调优路径，建议补充更多场景。

当前仅测试 claude-sonnet-4-5 模型路径。applyAntigravityRequestTuning 对非 Claude 模型（如 gemini-2.5-flash）有不同的分支逻辑（删除 maxOutputTokens 而非设置 VALIDATED mode）。建议补充：

1. 非 Claude 模型的 Gemini 路径测试
2. 验证原始 systemInstruction.parts 内容（"original"）是否被追加保留
3. 空 payload / 缺失字段的边界情况

internal/adapter/provider/antigravity/response.go (1)

271-302: 流聚合后的响应构建逻辑合理，注意 sjson.Set 错误被忽略。

Lines 276-294 共有约 10 次 sjson.Set / sjson.SetRaw 调用，所有错误均被 _ 丢弃。虽然在这些上下文中失败概率很低（输入来自有效 JSON 解析），但若某次设置失败，后续操作会基于不完整的 responseTemplate 继续构建。对于关键路径的响应数据，建议至少在整体结果上做一次 gjson.Valid 检查。

internal/domain/model.go (1)

815-852: 这些辅助函数（containsWildcard、splitByWildcard、hasPrefix、hasSuffix、indexOf）现已成为死代码，建议删除。

MatchWildcard 已重写为使用独立的迭代式匹配算法实现，不再依赖这些辅助函数。在整个代码库中均未发现对这些函数的任何调用，包括测试文件，清理这些未使用的函数可以减少维护负担。

internal/adapter/provider/antigravity/transform_request.go (1)

56-82: 注释步骤编号不一致。

移除 safety settings 代码后，注释编号变得混乱：

• 第 53 行标注 "8. Build Gemini request"，但子步骤标注为 7.1-7.4（应为 8.1-8.4）
• 第 77 行标注 "5.5 deep-clean" 出现在步骤 7.4 之后
• 第 81 行标注 "6. Serialize" 出现在 "5.5" 之后

建议统一重新编号，保持逻辑清晰。

internal/adapter/provider/antigravity/openai_request.go (3)

170-182: data URL 解析逻辑重复且使用魔数。

用户消息（170-182 行）和助手消息（220-232 行）中的 data URL 解析逻辑完全相同，且使用了魔数 5（"data:" 长度）和 7（"base64," 长度）。建议提取为辅助函数以减少重复并提高可读性。

♻️ 提取辅助函数

// parseDataURL extracts MIME type and base64 data from a data URL.
// Returns ("", "", false) if the URL is not a valid data URL.
func parseDataURL(dataURL string) (mimeType, data string, ok bool) {
	const dataPrefix = "data:"       // len = 5
	const base64Marker = "base64,"   // len = 7
	if !strings.HasPrefix(dataURL, dataPrefix) {
		return "", "", false
	}
	pieces := strings.SplitN(dataURL[len(dataPrefix):], ";", 2)
	if len(pieces) != 2 || !strings.HasPrefix(pieces[1], base64Marker) {
		return "", "", false
	}
	return pieces[0], pieces[1][len(base64Marker):], true
}

---

404-404: itoa 可以使用 strconv.Itoa 替代。

fmt.Sprintf("%d", i) 比 strconv.Itoa(i) 慢且分配更多内存。在此文件中 itoa 被频繁调用（消息和工具处理循环中），建议使用标准库。

♻️ 建议修改

-func itoa(i int) string { return fmt.Sprintf("%d", i) }
+func itoa(i int) string { return strconv.Itoa(i) }

需要在 import 中添加 "strconv"。

---

19-25: 函数体量过大（~280 行），建议拆分。

ConvertOpenAIRequestToAntigravity 包含系统指令提取、消息转换、工具映射等多个不同职责，且有三遍消息遍历。考虑将消息处理（lines 90-293）和工具处理（lines 295-399）拆分为独立的辅助函数，提高可读性和可测试性。

internal/adapter/provider/antigravity/schema_cleaner.go (2)

422-427: append(unsupportedConstraints, ...) 可能在未来产生隐患。

虽然当前 Go slice literal 的 cap == len，append 会分配新数组不会修改全局变量，但这种对模块级变量直接 append 的写法容易被误读为修改原始 slice。建议显式构建新 slice 更清晰：

♻️ 建议修改

 func removeUnsupportedKeywords(jsonStr string) string {
-	keywords := append(unsupportedConstraints,
+	keywords := make([]string, 0, len(unsupportedConstraints)+7)
+	keywords = append(keywords, unsupportedConstraints...)
+	keywords = append(keywords,
 		"$schema", "$defs", "definitions", "const", "$ref", "additionalProperties",
-		"propertyNames", // Gemini doesn't support property name validation
+		"propertyNames",
 	)

---

14-14: gjsonPathKeyReplacer 与 translator_helpers.go 中的 keyReplacer 重复。

同一个包内 translator_helpers.go:Walk() 函数中定义了相同的 strings.NewReplacer(".", "\\.", "*", "\\*", "?", "\\?")。建议统一使用这里的包级变量 gjsonPathKeyReplacer，避免重复定义。

internal/converter/coverage_openai_response_test.go (1)

542-544: finish_reason 断言方式脆弱，依赖 JSON 序列化的字面文本。

strings.Contains(string(out), "finish_reason\":null") 对 JSON 序列化格式做了隐式假设（无空格、key 前缀恰好一致）。建议使用 gjson（本文件已引入）进行结构化断言，与 Lines 381-382 中的做法保持一致。

♻️ 建议修改

-	if !strings.Contains(string(out), "finish_reason\":null") {
-		t.Fatalf("expected empty finish reason")
+	if gjson.GetBytes(out, "choices.0.finish_reason").Exists() && gjson.GetBytes(out, "choices.0.finish_reason").Type != gjson.Null {
+		t.Fatalf("expected null finish_reason, got: %v", gjson.GetBytes(out, "choices.0.finish_reason").Value())
 	}

同样的问题也出现在 Lines 643-644。

internal/executor/middleware_egress.go (2)

55-55: _ = state.lastErr 是无操作的死代码。

访问结构体字段并赋值给空白标识符不会产生任何副作用。如果是为了将来使用可以加 // TODO 注释，否则建议直接移除。

---

35-35: 仓库 Update 错误被静默丢弃，建议至少记录日志。

_ = e.proxyRequestRepo.Update(proxyReq) 和 _ = e.attemptRepo.Update(state.currentAttempt) 的错误均被忽略。在 egress 清理阶段，持久化失败可能导致监控和审计数据不一致。参考 middleware_ingress.go Line 110 中对 Create 失败的处理模式，建议加上日志。

♻️ 建议修改

-		_ = e.proxyRequestRepo.Update(proxyReq)
+		if err := e.proxyRequestRepo.Update(proxyReq); err != nil {
+			log.Printf("[Executor] egress: failed to update proxy request: %v", err)
+		}

-		_ = e.attemptRepo.Update(state.currentAttempt)
+		if err := e.attemptRepo.Update(state.currentAttempt); err != nil {
+			log.Printf("[Executor] egress: failed to update upstream attempt: %v", err)
+		}

Also applies to: 49-49

internal/adapter/provider/codex/oauth.go (1)

279-421: codexUsageAPIResponse 中匿名结构体大量重复，建议提取为命名类型。

同一个 8 字段的 window 匿名结构体被复制了约 8 次，同一个 rate-limit 匿名结构体（含 Allowed、LimitReached、窗口等）也复制了 4 次。总计约 140 行几乎完全相同的定义。parseWindow 的参数已经在手动声明结构体类型了——可以将 window 和 rate-limit 块提取为包级命名类型，大幅减少重复。

♻️ 建议提取命名类型示例

+// codexAPIWindow is the raw API window supporting both snake_case and camelCase.
+type codexAPIWindow struct {
+	UsedPercent             *float64 `json:"used_percent,omitempty"`
+	UsedPercentCamel        *float64 `json:"usedPercent,omitempty"`
+	LimitWindowSeconds      *int64   `json:"limit_window_seconds,omitempty"`
+	LimitWindowSecondsCamel *int64   `json:"limitWindowSeconds,omitempty"`
+	ResetAfterSeconds       *int64   `json:"reset_after_seconds,omitempty"`
+	ResetAfterSecondsCamel  *int64   `json:"resetAfterSeconds,omitempty"`
+	ResetAt                 *int64   `json:"reset_at,omitempty"`
+	ResetAtCamel            *int64   `json:"resetAt,omitempty"`
+}
+
+// codexAPIRateLimit is the raw API rate limit supporting both naming conventions.
+type codexAPIRateLimit struct {
+	Allowed           *bool          `json:"allowed,omitempty"`
+	LimitReached      *bool          `json:"limit_reached,omitempty"`
+	LimitReachedCamel *bool          `json:"limitReached,omitempty"`
+	PrimaryWindow     *codexAPIWindow `json:"primary_window,omitempty"`
+	PrimaryWindowCamel *codexAPIWindow `json:"primaryWindow,omitempty"`
+	SecondaryWindow    *codexAPIWindow `json:"secondary_window,omitempty"`
+	SecondaryWindowCamel *codexAPIWindow `json:"secondaryWindow,omitempty"`
+}

然后 codexUsageAPIResponse 中直接引用：

 type codexUsageAPIResponse struct {
 	PlanType      string `json:"plan_type,omitempty"`
 	PlanTypeCamel string `json:"planType,omitempty"`
-	RateLimit     *struct { /* ~40 lines */ } `json:"rate_limit,omitempty"`
-	RateLimitCamel *struct { /* ~40 lines */ } `json:"rateLimit,omitempty"`
+	RateLimit      *codexAPIRateLimit `json:"rate_limit,omitempty"`
+	RateLimitCamel *codexAPIRateLimit `json:"rateLimit,omitempty"`
 	// ... same for CodeReviewRateLimit
 }

internal/executor/middleware_ingress.go (3)

121-121: GetBySessionID 错误被静默丢弃。

如果 repository 查询失败（数据库连接问题等），session 为 nil 后会创建一个空 session 继续执行。在数据库临时不可用场景下，这会导致新建不必要的 session 对象，并可能绕过已有的 project 绑定。建议至少记录日志。

♻️ 建议修改

-		session, _ := e.sessionRepo.GetBySessionID(state.sessionID)
+		session, err := e.sessionRepo.GetBySessionID(state.sessionID)
+		if err != nil {
+			log.Printf("[Executor] ingress: failed to get session %s: %v", state.sessionID, err)
+		}

---

22-75: 流上下文键提取重复模板代码较多，可考虑泛型辅助函数简化。

约 50 行 c.Get + 双层类型断言的重复模式。可用泛型辅助函数（Go 1.18+）减少样板代码。

♻️ 示例辅助函数

func flowGet[T any](c *flow.Ctx, key string) (T, bool) {
    v, ok := c.Get(key)
    if !ok {
        var zero T
        return zero, false
    }
    t, ok := v.(T)
    return t, ok
}

使用：

if ct, ok := flowGet[domain.ClientType](c, flow.KeyClientType); ok {
    state.clientType = ct
}

---

160-162: Line 162 state.ctx = ctx 是冗余赋值。

ctx 在 Line 22 从 state.ctx 读取，Line 118 已经将其赋回 state.ctx，此处再次赋值没有任何效果（ctx 局部变量未被修改）。

internal/converter/registry.go (2)

52-54: ResponseTransformerWithState 接口——建议补充文档注释。

该接口缺少 Go doc 注释，与同文件中其他接口（如 RequestTransformer、ResponseTransformer）的风格不一致。建议添加注释说明其用途和与 ResponseTransformer 的关系。

♻️ 建议补充注释

+// ResponseTransformerWithState extends response transformation with per-request state.
+// Transformers implementing this interface will be preferred over ResponseTransformer.Transform
+// when TransformResponseWithState is called with a non-nil state.
 type ResponseTransformerWithState interface {
 	TransformWithState(body []byte, state *TransformState) ([]byte, error)
 }

---

186-188: mustMarshal 静默忽略序列化错误，可能导致下游空数据。

json.Marshal 失败时返回 nil，调用方若未检查返回值，可能产生空字节切片被写入响应。虽然对基本类型不太可能失败，但 must 前缀通常暗示会 panic 而非静默失败。

♻️ 建议：要么 panic（匹配 must 语义），要么改名并返回 error

 func mustMarshal(v interface{}) []byte {
-	b, _ := json.Marshal(v)
+	b, err := json.Marshal(v)
+	if err != nil {
+		panic(fmt.Sprintf("mustMarshal: %v", err))
+	}
 	return b
 }

internal/executor/converting_writer.go (2)

253-262: updateContentType 三个分支设置了相同的 Content-Type。

所有分支均设置 "application/json"，可以简化。如果未来不会有差异化需求，建议合并。

♻️ 简化建议

 func (c *ConvertingResponseWriter) updateContentType() {
-	switch c.originalType {
-	case domain.ClientTypeClaude:
-		c.underlying.Header().Set("Content-Type", "application/json")
-	case domain.ClientTypeOpenAI:
-		c.underlying.Header().Set("Content-Type", "application/json")
-	case domain.ClientTypeGemini:
-		c.underlying.Header().Set("Content-Type", "application/json")
-	}
+	if c.originalType != "" {
+		c.underlying.Header().Set("Content-Type", "application/json")
+	}
 }

---

279-318: GetPreferredTargetType 中 OpenAI 类型不在优先级链中。

当 providerType != "codex" 时，优先级顺序为 Gemini → Claude → 第一个支持类型 → originalType。如果 supportedTypes 中只有 openai，会走到 Line 313 的 fallback 返回 supportedTypes[0]，这是正确的。但建议在注释中明确说明 OpenAI 不需要显式偏好，因为大多数客户端本身就是 OpenAI 格式。

internal/converter/codex_to_openai.go (1)

419-446: buildReverseMapFromOriginalOpenAI 在 original 为 nil 时仍调用 gjson.GetBytes(nil, ...)。

gjson.GetBytes(nil, ...) 返回空 Result，功能上是安全的，会返回空 map。但 Line 168 传入 nil 再由 Line 169-171 可能覆盖为有效值——这段逻辑可以简化，避免不必要的空 map 创建。

♻️ 简化建议

-		rev := buildReverseMapFromOriginalOpenAI(nil)
-		if state != nil && len(state.OriginalRequestBody) > 0 {
-			rev = buildReverseMapFromOriginalOpenAI(state.OriginalRequestBody)
-		}
+		var originalBody []byte
+		if state != nil {
+			originalBody = state.OriginalRequestBody
+		}
+		rev := buildReverseMapFromOriginalOpenAI(originalBody)

internal/converter/codex_openai_stream_test.go (1)

45-53: 建议提取重复的 SSE 事件驱动循环为测试辅助函数。

TestCodexToOpenAIStreamToolCalls（Lines 45-53）和 TestCodexToClaudeStreamToolStopReason（Lines 129-137）中的事件循环逻辑完全一致。可以提取为 transformEvents(t, conv, state, events) 辅助函数减少重复。

Also applies to: 129-137

internal/handler/proxy.go (2)

161-211: Flow context 中存在重复的键设置。

以下键存在语义重复：

• KeyIsStream（Line 169）与 KeyProxyStream（Line 209）
• KeyRequestModel（Line 163）与 KeyProxyRequestModel（Line 210）

dispatch 方法（Line 217-221）还需要从 KeyProxyStream 重新读取 stream 值。如果这些键的用途不同（例如一个是原始值，另一个是中间件可修改的值），建议在键常量定义处添加注释说明区别；否则应统一使用一个键。

---

130-130: r.WithContext(ctx) 是冗余操作。

Line 130 ctx := r.Context()，Line 204 r = r.WithContext(ctx) —— 将请求的 context 取出后又原封不动地设置回去，没有实际效果，仅产生不必要的对象分配。

♻️ 建议移除冗余代码

-	ctx := r.Context()
 	clientType := h.clientAdapter.DetectClientType(r, body)
 ...
-	r = r.WithContext(ctx)
-	c.Request = r
+	c.Request = r

如果后续确实需要向 context 中注入值，应改为 r = r.WithContext(context.WithValue(ctx, key, val))。

Also applies to: 204-205

internal/executor/middleware_dispatch.go (1)

309-328: 上下文取消检测逻辑存在冗余判断。

Line 310：if ok && ctx.Err() != nil —— 检查是否为 ProxyError 且 context 已取消。
Line 330：if ok && ctx.Err() != context.Canceled —— 检查是否为 ProxyError 且 context 未被取消（可能是 DeadlineExceeded 或其他情况）。

但 Line 310 的分支已经处理了 ctx.Err() != nil 并 return，所以 Line 330 执行时 ctx.Err() 理论上为 nil（除非在 310-329 之间 context 状态变化）。这意味着 Line 330 的 ctx.Err() != context.Canceled 条件始终为 true（因为 nil != context.Canceled），该条件检查是多余的。

♻️ 简化条件判断

-		if ok && ctx.Err() != context.Canceled {
+		if ok {
 			log.Printf("[Executor] ProxyError - IsNetworkError: %v, IsServerError: %v, Retryable: %v, Provider: %d",
 				proxyErr.IsNetworkError, proxyErr.IsServerError, proxyErr.Retryable, matchedRoute.Provider.ID)
 			e.handleCooldown(proxyErr, matchedRoute.Provider, currentClientType, originalClientType)

同时可以移除 Line 339 的 else if ok && ctx.Err() == context.Canceled 分支，因为已不可达。

internal/converter/codex_to_claude.go (2)

287-294: msgDelta["usage"] 的类型断言较脆弱

第 293 行 msgDelta["usage"].(map[string]int) 直接对刚在第 287-290 行创建的值做类型断言。虽然目前不会 panic，但如果将来有人修改第 287 行的值类型，这里会在运行时崩溃。建议提取为局部变量复用。

建议的改动

-			msgDelta := map[string]interface{}{
+			usageMap := map[string]int{
+				"input_tokens":  inputTokens,
+				"output_tokens": outputTokens,
+			}
+			if cachedTokens > 0 {
+				usageMap["cache_read_input_tokens"] = cachedTokens
+			}
+			msgDelta := map[string]interface{}{
 				"type": "message_delta",
 				"delta": map[string]interface{}{
 					"stop_reason": stopReason,
 				},
-				"usage": map[string]int{
-					"input_tokens":  inputTokens,
-					"output_tokens": outputTokens,
-				},
-			}
-			if cachedTokens > 0 {
-				msgDelta["usage"].(map[string]int)["cache_read_input_tokens"] = cachedTokens
+				"usage": usageMap,
 			}

---

436-459: tools.Array() 被重复调用

第 439 行 len(tools.Array()) > 0 和第 441 行 arr := tools.Array() 分别调用了 tools.Array()，每次调用都会分配一个新切片。建议只调用一次。

建议的改动

 func buildReverseMapFromClaudeOriginalShortToOriginal(original []byte) map[string]string {
 	tools := gjson.GetBytes(original, "tools")
 	rev := map[string]string{}
-	if tools.IsArray() && len(tools.Array()) > 0 {
-		var names []string
-		arr := tools.Array()
+	arr := tools.Array()
+	if len(arr) > 0 {
+		var names []string
 		for i := 0; i < len(arr); i++ {

internal/flow/helpers.go (1)

10-152: 可考虑使用泛型减少样板代码

16 个 helper 函数全部遵循相同模式：c.Get(key) → 类型断言 → 返回。Go 1.18+ 可用泛型大幅简化：

func getValue[T any](c *Ctx, key string) T {
    if v, ok := c.Get(key); ok {
        if t, ok := v.(T); ok {
            return t
        }
    }
    var zero T
    return zero
}

// 用法:
func GetClientType(c *Ctx) domain.ClientType { return getValue[domain.ClientType](c, KeyClientType) }
func GetSessionID(c *Ctx) string             { return getValue[string](c, KeySessionID) }
// ...

当前写法也没有问题，只是维护成本略高。可作为后续优化。

internal/adapter/provider/antigravity/adapter.go (1)

554-573: isAntigravityEndpoint 包含冗余检查

第 560 行 cloudcode-pa.googleapis.com 已经涵盖了第 563 行 daily-cloudcode-pa.googleapis.com 的匹配（因为使用 strings.Contains）。第 569 行的组合检查也被前面的条件覆盖。可以简化逻辑。

internal/adapter/provider/kiro/adapter.go (1)

705-732: HTTP 客户端未设置整体 Timeout

注释说明是为了匹配 kiro2api 行为，但缺少 Timeout 意味着请求可能无限挂起。建议至少设置一个较大的兜底超时（如 10 分钟），以防止连接泄漏。

internal/converter/openai_to_codex.go (5)

23-28: json.Unmarshal 仅用于验证但结果未使用

第 24-27 行反序列化为 interface{} 仅用于校验 JSON 合法性，但 tmp 变量后续未使用。第 28 行 bytes.Clone(body) 也非必要，因为 gjson 不会修改输入。如果只需验证 JSON 合法性，可使用 json.Valid(body)。

建议的改动

 func (c *openaiToCodexRequest) Transform(body []byte, model string, stream bool) ([]byte, error) {
-	var tmp interface{}
-	if err := json.Unmarshal(body, &tmp); err != nil {
+	if !json.Valid(body) {
-		return nil, err
+		return nil, fmt.Errorf("invalid JSON input")
 	}
-	rawJSON := bytes.Clone(body)
+	rawJSON := body
 	out := `{"instructions":""}`

---

250-253: TransformWithState 中同样存在冗余的 JSON 验证

与 Transform 一样，第 251-253 行的 json.Unmarshal 仅用于验证。可统一改为 json.Valid(body)。

---

670-714: 手写冒泡排序出现多次，建议使用 slices.Sort 或 sort.Ints

第 676-682、726-732、780-786、803-808 行均使用手写冒泡排序对 []int 排序。标准库 sort.Ints() 或 Go 1.21+ 的 slices.Sort() 更简洁且不易出错。

示例改动（以第 672-682 行为例）

+import "sort"
+
 				if len(st.MsgItemAdded) > 0 {
 					idxs := make([]int, 0, len(st.MsgItemAdded))
 					for i := range st.MsgItemAdded {
 						idxs = append(idxs, i)
 					}
-					for i := 0; i < len(idxs); i++ {
-						for j := i + 1; j < len(idxs); j++ {
-							if idxs[j] < idxs[i] {
-								idxs[i], idxs[j] = idxs[j], idxs[i]
-							}
-						}
-					}
+					sort.Ints(idxs)

---

396-851: convertOpenAIChatCompletionsChunkToResponses 超过 450 行，建议拆分

该函数是一个大型状态机，处理 OpenAI 流式到 Codex 流式的转换。可考虑按职责拆分为若干子函数：

• 初始化逻辑（Started 检查 + 初始事件发射）→ emitResponseStart
• 内容 delta 处理 → handleContentDelta
• 推理内容处理 → handleReasoningDelta
• 工具调用处理 → handleToolCallDelta
• 完成事件处理 → handleFinishReason

这样也有助于单元测试各子路径。

---

841-843: 使用 state.OriginalRequestBody 前未检查 state 是否为 nil

第 841 行直接访问 state.OriginalRequestBody，但 state 可能为 nil（虽然第 397-399 行在函数入口有 nil 返回，但 convertOpenAIChatCompletionsChunkToResponses 是从 TransformChunk 调用的，state 来自外部）。在此处 state 实际上不会为 nil（因为第 397 行已检查），但若将来代码路径变更，此处缺少防护。如果确信 state 不会为 nil 可以忽略。

internal/adapter/provider/custom/adapter.go (1)

43-51: context.Background() 回退模式的一致性注意。

当 c.Request 为 nil 时使用 context.Background() 作为兜底，这意味着上游请求将没有超时/取消传播。同样的模式在 handleStreamResponse（Line 335-338）中也出现了。如果 c.Request 在生产环境中不可能为 nil，可考虑直接断言或返回错误，避免静默降级。

internal/adapter/provider/codex/adapter.go (2)

97-108: stream 字段被重复设置。

applyCodexRequestTuning（Line 552）已将 body 中的 "stream" 设为 true，紧接着 Lines 105-107 又通过 sjson.SetBytes 再次设置为 true。可以移除其中一处以避免混淆。

♻️ 建议移除重复设置

由于 applyCodexRequestTuning 已经设置了 stream，可以移除 Lines 103-108：

 	cacheID, updatedBody := applyCodexRequestTuning(c, requestBody)
 	requestBody = updatedBody

 	// Build upstream URL
 	upstreamURL := CodexBaseURL + "/responses"
-	upstreamStream := true
-	if len(requestBody) > 0 {
-		if updated, err := sjson.SetBytes(requestBody, "stream", upstreamStream); err == nil {
-			requestBody = updated
-		}
-	}
+	upstreamStream := true

同时在 applyCodexRequestTuning 中保留 stream 设置作为唯一来源。

---

420-424: response.completed 的字符串匹配可能产生误判。

Line 422 使用 strings.Contains(line, "\"response.completed\"") 来检测完成事件。如果消息内容中恰好包含 "response.completed" 字符串（如用户讨论 API 事件类型），会导致误判 responseCompleted = true。建议解析 JSON 后检查 type 字段，或至少使用更精确的匹配。

当前影响较低（仅影响提前标记完成状态），但在边缘场景下可能掩盖真正的断连错误。

internal/converter/coverage_openai_stream_test.go (1)

516-527: 流末尾追加 FormatDone() 后，建议补充对 [DONE] 标记的转发断言。

当前测试在第 518 行新增了 FormatDone() 到流尾部，但后续断言（第 524 行）仅验证输出包含 "chat.completion.chunk"，并未验证 codexToOpenAIResponse 是否正确地将 [DONE] 传递到输出流中。如果 Codex-to-OpenAI 转换器应当在末尾输出 [DONE]，建议增加类似断言：

if !strings.Contains(string(out), "[DONE]") {
    t.Fatalf("expected [DONE] marker in output")
}

如果转换器设计上不转发 [DONE]，可忽略此建议。

internal/executor/middleware_route_match.go (1)

27-57: 两个错误分支存在大量重复代码，建议提取辅助函数。

err != nil 和 len(routes) == 0 两个分支的逻辑几乎相同（设置 proxyReq 状态、计算 Duration、更新仓库、广播、设置错误并 Abort）。可以抽取一个 failRouteMatch 辅助方法来消除重复。

♻️ 建议重构

+func (e *Executor) failRouteMatch(c *flow.Ctx, state *execState, errMsg string) {
+	proxyReq := state.proxyReq
+	proxyReq.Status = "FAILED"
+	proxyReq.Error = errMsg
+	proxyReq.EndTime = time.Now()
+	proxyReq.Duration = proxyReq.EndTime.Sub(proxyReq.StartTime)
+	_ = e.proxyRequestRepo.Update(proxyReq)
+	if e.broadcaster != nil {
+		e.broadcaster.BroadcastProxyRequest(proxyReq)
+	}
+	err := domain.NewProxyErrorWithMessage(domain.ErrNoRoutes, false, errMsg)
+	state.lastErr = err
+	c.Err = err
+	c.Abort()
+}

internal/adapter/provider/codex/adapter_test.go (1)

11-37: 测试覆盖了核心行为，但建议补充对 model 字段保留和 user_id 提取的断言。

当前测试验证了缓存 ID 生成、stream 强制设为 true 以及敏感字段移除，这些是核心逻辑。但缺少以下验证：

• model 字段是否被原样保留（"gpt-5"）
• 从 KeyOriginalRequestBody 中提取的 user_id 是否被正确使用（如果 applyCodexRequestTuning 涉及该逻辑）

此外，flow.NewCtx(nil, nil) 传入了 nil 的 Writer 和 Request，如果被测函数未来访问这些字段会导致 panic。建议使用 httptest.NewRecorder() 和 httptest.NewRequest() 以提高健壮性。

internal/adapter/provider/antigravity/response.go (1)

275-295: sjson.Set / sjson.SetRaw 的错误均被丢弃。

Lines 276-294 中多次调用 sjson.Set 和 sjson.SetRaw，返回的错误全部被 _ 忽略。虽然 sjson 在正常模板上很少出错，但如果 responseTemplate 因解析异常导致格式不正确（例如上游返回截断的 JSON），这些静默失败会使输出数据不完整且难以排查。

建议对关键字段（至少 candidates.0.content.parts）的设置做错误检查并记录日志。

internal/domain/model.go (1)

856-893: 旧辅助函数已变为死代码。

containsWildcard、splitByWildcard、hasPrefix、hasSuffix、indexOf 在 MatchWildcard 重写后不再被调用。如果包内或包外无其他引用，建议移除以减少维护负担。

#!/bin/bash
# 检查这些辅助函数是否在其他地方被引用
for fn in containsWildcard splitByWildcard hasPrefix hasSuffix indexOf; do
  echo "=== $fn ==="
  rg -n --type=go "\b$fn\b" -g '!internal/domain/model.go'
done

internal/converter/registry.go (2)

52-54: ResponseTransformerWithState 缺少文档注释。

其他接口（RequestTransformer、ResponseTransformer）均有 Go doc 注释，此处应保持一致。

建议添加注释

+// ResponseTransformerWithState extends ResponseTransformer with stateful non-streaming response conversion.
 type ResponseTransformerWithState interface {
 	TransformWithState(body []byte, state *TransformState) ([]byte, error)
 }

---

140-158: TransformResponseWithState 中 state 为 nil 时可安全传递给 TransformWithState，但缺乏防御性保护。

当前调用路径（converting_writer.go 的 Finalize）总会传入非 nil 的 state，但此方法为公开 API。若未来有新调用者传入 nil，下游的 TransformWithState 实现（如 codexToOpenAIResponse、openaiToCodexResponse）在访问 state.OriginalRequestBody 时会 panic。

可考虑在入口处做防御性检查，或在文档中明确标注 state 不可为 nil。

internal/converter/gemini_to_openai.go (2)

271-301: 每个 SSE 事件同时进行 json.Unmarshal（Line 272）和 gjson.ParseBytes（Line 275）——双重解析。

event.Data 在循环中先通过 json.Unmarshal 解析为 GeminiStreamChunk，再通过 gjson.ParseBytes 提取元数据字段。对于高频流式场景，这会带来额外开销。

可考虑统一使用 gjson 提取所有字段（包括 candidates），或将结构化反序列化的结果与 gjson 查询合并，避免两次解析同一份 JSON。当前不影响正确性，属于优化建议。

---

326-339: 各分支中 OpenAIStreamChunk 构造逻辑高度重复。

thinking、text、inline_data、function_call、finish 五个分支的 chunk 构造代码结构几乎相同（设置 ID、Object、Created、Model、createdAt 覆盖），仅 Delta 内容不同。可考虑提取一个 helper 函数来减少重复，例如：

func newGeminiOpenAIChunk(state *TransformState, meta *geminiOpenAIStreamMeta, createdAt int64) OpenAIStreamChunk {
    c := OpenAIStreamChunk{
        ID: state.MessageID, Object: "chat.completion.chunk",
        Created: time.Now().Unix(), Model: meta.Model,
    }
    if createdAt > 0 { c.Created = createdAt }
    return c
}

这与 codex_to_openai.go 中的 newOpenAIStreamTemplate 思路一致。非阻塞建议。

Also applies to: 342-356, 358-378, 380-408, 416-432

internal/converter/openai_to_codex.go (2)

23-28: json.Unmarshal 到 interface{} 仅用于验证——可以更轻量。

Line 24-27 将 body 反序列化到 var tmp interface{} 但从未使用 tmp，仅为验证 JSON 有效性。随后 Line 28 又 bytes.Clone(body) 获取原始字节。TransformWithState（Line 251-253）也有相同模式。

若仅需验证 JSON 合法性，可使用 json.Valid(body) 代替，避免不必要的内存分配。

♻️ 建议

-	var tmp interface{}
-	if err := json.Unmarshal(body, &tmp); err != nil {
+	if !json.Valid(body) {
+		err := json.Unmarshal(body, &json.RawMessage{})
 		return nil, err
 	}
-	rawJSON := bytes.Clone(body)
+	rawJSON := bytes.Clone(body)

或直接信任上游已验证的输入，跳过此步骤。

---

78-81: 变量 c 遮蔽了方法接收者。

Line 80 的 c := m.Get("content") 遮蔽了方法接收者 c *openaiToCodexRequest。虽然当前不影响功能（此分支后续未再使用接收者），但在后续维护时容易引发混淆。建议改用不同变量名，如 contentVal。

♻️ 建议

-			c := m.Get("content")
-			if c.Exists() && c.Type == gjson.String && c.String() != "" {
+			contentVal := m.Get("content")
+			if contentVal.Exists() && contentVal.Type == gjson.String && contentVal.String() != "" {

后续对 c 的引用也需相应替换。

internal/flow/engine.go (1)

57-69: Next() 中 handler 自身调用 c.Next() 时的递归行为——确认符合预期。

当 handler 内部调用 c.Next() 时，c.index 在递归 Next() 中被推进。递归返回后，外层循环继续 c.index++，由于 index 已超过 len(handlers)，循环立即退出。这与 Gin 框架的行为一致，但没有显式文档说明。

如果团队中有人不熟悉此模式，建议在 Next() 方法上添加简短注释说明递归调用语义。

internal/flow/helpers.go (1)

10-152: 考虑使用泛型辅助函数减少重复代码。

这 16 个 helper 函数的结构完全一致（取值 → 类型断言 → 返回默认值），可以引入一个泛型辅助函数统一处理：

♻️ 泛型重构示例

func getTyped[T any](c *Ctx, key string, defaultVal T) T {
	if v, ok := c.Get(key); ok {
		if t, ok := v.(T); ok {
			return t
		}
	}
	return defaultVal
}

// 使用示例:
func GetClientType(c *Ctx) domain.ClientType {
	return getTyped[domain.ClientType](c, KeyClientType, "")
}

func GetProjectID(c *Ctx) uint64 {
	return getTyped[uint64](c, KeyProjectID, 0)
}

这样可以将 16 个函数体简化为单行调用，消除重复逻辑，同时保持类型安全。

internal/adapter/provider/antigravity/openai_request.go (3)

170-182: Data URL 解析逻辑脆弱，依赖硬编码偏移量。

imageURL[5:] 假设前缀为 "data:"，pieces[1][7:] 假设前缀为 "base64,"，但没有显式验证这些前缀。如果 URL 格式略有不同（如缺少 data: 前缀或使用其他编码方式），可能导致索引越界或数据截断。

此外，Lines 220-232 中对 assistant 消息有完全相同的解析逻辑，建议抽取为公共函数。

♻️ 建议抽取 data URL 解析

// parseDataURL extracts MIME type and base64 data from a data URL.
// Returns ("", "", false) if the URL is not a valid data URL.
func parseDataURL(dataURL string) (mimeType, data string, ok bool) {
	if !strings.HasPrefix(dataURL, "data:") {
		return "", "", false
	}
	rest := dataURL[5:] // skip "data:"
	pieces := strings.SplitN(rest, ";", 2)
	if len(pieces) != 2 || !strings.HasPrefix(pieces[1], "base64,") {
		return "", "", false
	}
	return pieces[0], pieces[1][7:], true
}

---

404-404: itoa 使用 fmt.Sprintf 效率较低。

在高频调用路径中，strconv.Itoa 比 fmt.Sprintf 更高效且语义更清晰。

♻️ 建议

-func itoa(i int) string { return fmt.Sprintf("%d", i) }
+func itoa(i int) string { return strconv.Itoa(i) }

同时在 import 中添加 "strconv"。

---

19-25: 大量 sjson.SetBytes 调用丢弃了错误返回值。

整个函数中几乎所有 sjson.SetBytes 调用都使用 out, _ = 丢弃错误。虽然 sjson 在正常情况下很少返回错误，但在构建复杂嵌套结构时，静默忽略错误可能导致难以调试的数据丢失。建议至少在关键路径上记录错误日志，与文件中其他地方（如 Lines 310-316）处理 errSet 的模式保持一致。

internal/adapter/provider/antigravity/request.go (1)

67-75: Execute 中创建 context.Background() 作为后备，但会丢失请求级别的 context 传播。

当 c.Request 为 nil 时回退到 context.Background() 是安全的防御编码，但如果 flow.Ctx 本身应该携带 context，建议考虑在 flow.Ctx 上提供统一的 context 获取方法，避免在多个 adapter 中重复此模式（同样出现在 kiro adapter 中）。

internal/adapter/provider/antigravity/request_test.go (1)

9-43: 测试覆盖范围有限，建议补充 Gemini 路径和边界情况测试。

当前测试仅覆盖了 Claude 模型的调优路径。applyAntigravityRequestTuning 中还有 Gemini 模型的分支（使用 CleanJSONSchemaForGemini、删除 maxOutputTokens 等），这些逻辑未被测试到。

建议额外添加：

1. Gemini 模型的调优测试（非 Claude 分支）
2. 验证原始 systemInstruction.parts 中的 "original" 文本是否被保留在 parts[2]
3. 空 payload 或无效 JSON 输入的边界情况

internal/converter/codex_to_claude.go (1)

342-421: output.ForEach 闭包中修改外部变量 out 和 hasToolCall — 功能正确但需注意。

gjson.Result.ForEach 的回调闭包通过捕获修改了 out（string）和 hasToolCall（bool）。由于 ForEach 是同步执行的，这在功能上是正确的。但 out 作为 string 在闭包内被 sjson.Set 反复重新赋值，且整个闭包体较长（约 80 行），建议考虑将各 case 分支提取为独立函数以提升可读性。

internal/adapter/provider/kiro/adapter.go (1)

114-123: 上游请求头在初始请求和重试路径中完全重复。

Lines 114-123 和 Lines 158-166 的 header 设置逻辑完全一致（包括硬编码的 user-agent 字符串）。建议提取为辅助方法，减少重复并确保两条路径始终保持一致。

♻️ 重构建议

func setKiroUpstreamHeaders(req *http.Request, accessToken string, stream bool) {
	req.Header.Set("Authorization", "Bearer "+accessToken)
	req.Header.Set("Content-Type", "application/json")
	if stream {
		req.Header.Set("Accept", "text/event-stream")
	}
	req.Header.Set("x-amzn-kiro-agent-mode", "spec")
	req.Header.Set("x-amz-user-agent", "aws-sdk-js/1.0.18 KiroIDE-0.2.13-...")
	req.Header.Set("user-agent", "aws-sdk-js/1.0.18 ua/2.1 ...")
}

Also applies to: 158-166

internal/adapter/provider/codex/adapter.go (2)

118-129: stream 字段被重复设置为 true。

applyCodexRequestTuning（Line 119）内部已在 Line 573-575 将 body 中的 stream 设为 true，随后 Lines 125-129 再次用 sjson.SetBytes 将 stream 设为 upstreamStream（也是 true）。两处操作冗余。

建议从 applyCodexRequestTuning 中移除设置 stream 的逻辑，或移除 Execute 中的重复设置，保持单一职责。

---

679-700: extractCodexCompletedResponse 使用 50MB scanner buffer，建议添加注释说明原因。

Line 681 设置了 scanner.Buffer(nil, 52_428_800)（约 50MB）。对于正常 SSE 响应这个值偏大。如果确有需要（如超大 response.completed 事件），建议添加注释说明；否则可考虑降低上限以避免意外的高内存分配。

internal/converter/tool_name.go (1)

48-68: makeUnique 无限循环缺少安全上限。

当所有候选名都被占用时（理论上不太可能，但属于防御性编程），for i := 1; ; i++ 会无限循环。建议加一个合理的上限并在超出时返回错误或 fallback，避免极端场景下的 goroutine 挂起。

♻️ 建议加上限

 	makeUnique := func(cand string) string {
 		if _, ok := used[cand]; !ok {
 			return cand
 		}
 		base := cand
-		for i := 1; ; i++ {
+		for i := 1; i <= 10000; i++ {
 			suffix := "_" + strconv.Itoa(i)
 			allowed := maxToolNameLen - len(suffix)
 			if allowed < 0 {
 				allowed = 0
 			}
 			tmp := base
 			if len(tmp) > allowed {
 				tmp = tmp[:allowed]
 			}
 			tmp = tmp + suffix
 			if _, ok := used[tmp]; !ok {
 				return tmp
 			}
 		}
+		return cand // fallback — 实际不应触发
 	}

internal/executor/middleware_ingress.go (3)

22-75: 从 flow 上下文提取状态的样板代码过多，建议抽取辅助函数。

22-75 行连续 10 个几乎相同的 c.Get(key) + 双层类型断言模式，阅读负担较重。可以考虑封装泛型辅助函数来减少重复：

func getTyped[T any](c *flow.Ctx, key string) (T, bool) {
    v, ok := c.Get(key)
    if !ok {
        var zero T
        return zero, false
    }
    t, ok := v.(T)
    return t, ok
}

这样每次提取可简化为一行：

if ct, ok := getTyped[domain.ClientType](c, flow.KeyClientType); ok {
    state.clientType = ct
}

---

120-121: GetBySessionID 错误被静默忽略。

第 121 行 session, _ := e.sessionRepo.GetBySessionID(state.sessionID) 丢弃了错误。如果数据库出错（非"未找到"），此处会把 session 当作 nil 处理，继续创建临时 session 并尝试等待 project 绑定。建议至少记录日志以辅助排查。

---

160-162: 第 162 行 state.ctx = ctx 赋值冗余。

ctx 在第 22 行从 state.ctx 读出，此后未被修改，第 162 行又赋值回去，没有实际效果。可移除。

♻️ 清理

 		state.projectID = session.ProjectID
 		proxyReq.ProjectID = state.projectID
-		state.ctx = ctx
 	}

internal/handler/proxy.go (4)

58-60: Use 方法缺少并发安全性说明或保护。

Use 直接 append 到 h.extra，没有加锁。如果在服务启动后仍可能调用 Use（与 ServeHTTP 并发），则存在数据竞争。即使目前只在初始化阶段调用，也建议加文档注释说明"必须在 ServeHTTP 前调用"或添加锁保护，防止后续误用。

---

75-213: ingress 方法职责过多，建议拆分。

ingress 承担了请求校验、body 读取/规范化、客户端检测、token 认证、session 管理、project ID 解析、flow context 填充等多项职责（约 140 行）。这使得测试和维护都比较困难。

考虑将功能拆分为更小的中间件或辅助方法，例如：

• 请求校验 + body 读取
• 客户端检测 + token 认证
• session / project 解析
• flow context 填充

这与 PR 标题"中间件架构"的设计意图也更契合。

---

101-103: 直接修改 r.URL.Path 会影响原始请求对象。

第 102 行 r.URL.Path = strings.TrimPrefix(r.URL.Path, "/v1") 直接修改了传入的 *http.Request 的 URL，可能影响日志、中间件、或其他引用同一 request 的逻辑。考虑在需要转发时再修改，或者使用 r.Clone() / 局部变量避免副作用。

---

215-241: dispatch 错误处理合理。

区分了 ProxyError（502 / SSE error event）与通用错误（500），流式与非流式路径分开处理。逻辑正确。

一个小注意点：第 238 行 writeError(c.Writer, http.StatusInternalServerError, err.Error()) 会将内部错误信息直接暴露给客户端，在生产环境中可能泄露实现细节。建议考虑返回通用错误消息。

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

internal/adapter/provider/cliproxyapi_antigravity/adapter.go (1)

244-274: extractModelFromResponse 和 extractModelFromSSE 与 codex adapter 完全重复。

这两个 helper 函数在 cliproxyapi_antigravity 和 cliproxyapi_codex 中完全一致（参见 cliproxyapi_codex/adapter.go Lines 207-237）。建议提取到共享的 helper 包中以消除重复。

internal/adapter/provider/codex/adapter.go (2)

117-128: stream 字段被双重设置。

Line 118 调用 applyCodexRequestTuning 内部已在 Line 572 设置 body.stream = true，随后 Line 123-128 又通过 sjson.SetBytes 再次设置。虽然结果正确（幂等操作），但冗余逻辑增加了理解成本。

♻️ 建议移除冗余设置

由于 applyCodexRequestTuning 已处理 stream 字段，可以移除 Line 123-128 的重复设置：

 	// Apply Codex CLI payload adjustments (CLIProxyAPI-aligned)
 	cacheID, updatedBody := applyCodexRequestTuning(c, requestBody)
 	requestBody = updatedBody

 	// Build upstream URL
 	upstreamURL := CodexBaseURL + "/responses"
-	upstreamStream := true
-	if len(requestBody) > 0 {
-		if updated, err := sjson.SetBytes(requestBody, "stream", upstreamStream); err == nil {
-			requestBody = updated
-		}
-	}
+	upstreamStream := true

---

679-700: extractCodexCompletedResponse 的 scanner buffer 上限为 50MB，可能过大。

Line 681 scanner.Buffer(nil, 52_428_800) 设置了约 50MB 的最大行长度。对于正常的 SSE 响应来说这个值偏大，建议评估实际响应体大小并适当降低，或者添加注释说明选择此值的原因。

internal/adapter/provider/antigravity/adapter.go (2)

576-595: isAntigravityEndpoint 的域名白名单检查存在冗余。

Line 582 检查 cloudcode-pa.googleapis.com 已覆盖 Line 585 的 daily-cloudcode-pa.googleapis.com（子串匹配）。同时 Line 591 的组合条件也已被前面的检查覆盖。建议简化逻辑。

♻️ 简化建议

 func isAntigravityEndpoint(endpoint string) bool {
 	endpoint = strings.ToLower(strings.TrimSpace(endpoint))
 	if endpoint == "" {
 		return false
 	}
-	if strings.Contains(endpoint, "cloudcode-pa.googleapis.com") {
-		return true
-	}
-	if strings.Contains(endpoint, "daily-cloudcode-pa.googleapis.com") {
-		return true
-	}
-	if strings.Contains(endpoint, "daily-cloudcode-pa.sandbox.googleapis.com") {
-		return true
-	}
-	if strings.Contains(endpoint, "/v1internal") && strings.Contains(endpoint, "cloudcode-pa") {
-		return true
-	}
-	return false
+	return strings.Contains(endpoint, "cloudcode-pa")
 }

如果需要更严格的匹配（排除 cloudcode-pa-something-else.example.com），可保留 cloudcode-pa.googleapis.com 和 cloudcode-pa.sandbox.googleapis.com 两个检查。

---

80-402: Execute 方法过于庞大（~320 行），建议拆分。

当前 Execute 方法包含 token 获取、请求转换、多端点重试、401 刷新、错误处理、stream/non-stream 分发等逻辑。建议将内层的端点重试循环和错误处理提取为独立方法（如 executeWithRetry），以降低认知复杂度、提升可维护性。

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

internal/adapter/provider/antigravity/response.go (2)

169-188: json.Unmarshal 错误被静默忽略，可能导致数据丢失。

第 171 行 _ = json.Unmarshal([]byte(partResult.Raw), &m) 忽略了解析错误。虽然第 172-173 行有 nil 保护，但当 partResult.Raw 存在但格式不合法时，会返回一个空 map 而非原始数据，可能丢失 part 内容。

在此场景下风险较低，因为 partResult 来自 gjson 解析的有效 JSON，但仍建议添加日志方便调试。

---

276-296: 多处 sjson.Set 错误被忽略，最终 payload 可能不完整。

第 276-295 行中，json.Marshal(parts) 和多个 sjson.Set/SetRaw 调用的错误均以 _ 丢弃。如果序列化或设置操作失败（例如非法 JSON），最终输出的 responseTemplate 可能缺少关键字段（如 parts、finishReason、usageMetadata）。

考虑到这是流转非流的关键路径，建议至少对 json.Marshal(parts) 的错误进行检查或记录日志。

internal/adapter/provider/antigravity/request.go (2)

328-337: systemInstruction.parts 读取与覆写存在时序依赖，建议添加注释说明。

第 329 行在覆写 parts.0 和 parts.1 之前读取了 partsResult（原始 parts 快照），然后在第 334-336 行将原始 parts 追加回去。逻辑上是正确的——先读后写保证了原始数据不丢失。但这个隐式的"先快照再覆写再追加"模式容易在后续维护中被打乱。

💡 建议添加注释

+		// Snapshot existing system instruction parts before overwriting index 0 and 1
 		partsResult := gjson.GetBytes(payload, "request.systemInstruction.parts")
 		payload, _ = sjson.SetBytes(payload, "request.systemInstruction.role", "user")
 		payload, _ = sjson.SetBytes(payload, "request.systemInstruction.parts.0.text", antigravitySystemInstruction)
 		payload, _ = sjson.SetBytes(payload, "request.systemInstruction.parts.1.text", fmt.Sprintf("Please ignore following [ignore]%s[/ignore]", antigravitySystemInstruction))
+		// Append original parts after the injected ones
 		if partsResult.Exists() && partsResult.IsArray() {

---

272-300: finalizeOpenAIWrappedRequest 中多处 sjson.SetBytes 错误被忽略。

第 284-298 行中所有 sjson.SetBytes / sjson.DeleteBytes 调用的错误均以 _ 丢弃。虽然这些操作在正常 JSON 输入下不太可能失败，但如果上游传入了畸形 payload，静默失败可能导致发送到 upstream 的请求缺少必要字段（如 project、requestId）。

与 wrapV1InternalRequest（第 261-266 行）的风格不一致——后者对 json.Marshal 做了错误检查。

internal/adapter/provider/codex/adapter.go (2)

116-124: context.Background() 作为后备可能导致取消信号丢失。

第 120 行 ctx := context.Background() 在 c.Request == nil 时使用无取消能力的 context。这意味着如果 flow context 中没有 HTTP request（例如在某些测试或内部调用场景下），所有带超时/取消的操作（如 token 刷新、upstream 请求）将无法被中断。

同样的模式在 handleStreamResponse（第 439 行）中也存在。

虽然这是防御性编程，但建议考虑从 flow context 本身获取可取消的 context，而非仅依赖 c.Request。

---

137-142: stream 标志被无条件覆盖为 true，upstreamStream 变量名可能误导。

第 137 行 upstreamStream := true 意味着无论客户端是否请求流式响应，upstream 请求始终以流式模式发送。第 589 行 applyCodexRequestTuning 中也无条件设置 "stream": true。

这个行为本身可能是有意为之（Codex API 始终使用 SSE），但变量命名和两处重复设置可能让后续维护者困惑。建议添加注释说明原因。

Also applies to: 589-591

internal/adapter/provider/antigravity/adapter.go (1)

207-401: 多层重试循环结构复杂但逻辑完整。

三层控制流（thinking 重试 → 端点重试 → 容量重试）配合 break/continue 跳转较难追踪。考虑在关键跳转处添加注释标注目标循环，提高可读性。当前实现中错误处理、资源释放和重试条件判断均正确。

internal/executor/middleware_ingress.go (1)

123-131: sessionRepo.GetBySessionID 错误被忽略，存在静默降级风险。

第 124 行 session, _ := e.sessionRepo.GetBySessionID(state.sessionID) 丢弃了错误。如果是数据库连接失败等可恢复错误，会静默创建一个临时 session（第 126-131 行），可能导致后续项目绑定行为异常。

建议至少记录日志：

💡 建议

-	session, _ := e.sessionRepo.GetBySessionID(state.sessionID)
+	session, sessErr := e.sessionRepo.GetBySessionID(state.sessionID)
+	if sessErr != nil {
+		log.Printf("[Executor] Failed to get session %s: %v", state.sessionID, sessErr)
+	}

internal/handler/proxy.go (2)

164-213: 请求数据存在两个来源：flow keys 和 Ctx 直接字段，容易不一致。

第 168 行设置了 flow.KeyRequestBody，第 209 行又设置了 c.InboundBody；第 172 行设置了 flow.KeyIsStream，第 210 行又设置了 c.IsStream。下游代码（如 adapter 使用 flow.GetRequestBody(c)，executor 使用 c.InboundBody）可能从不同来源读取相同数据。

如果后续中间件修改了其中一个而未同步更新另一个，会导致行为不一致。建议统一为单一数据来源，或在文档中明确哪个是权威数据。

---

78-81: ingress 中直接使用 c.Request 的 Method 和 URL.Path 未做 nil 检查。

第 81 行 log.Printf("[Proxy] Received request: %s %s", r.Method, r.URL.Path) 中 r 来自 c.Request。虽然在 ServeHTTP（第 71 行）中通过 flow.NewCtx(w, r) 创建时 r 不会为 nil（由 http.Server 保证），但如果 ingress 被其他路径调用（如测试中 flow.NewCtx(nil, nil)），则会 panic。

鉴于此 handler 只从 ServeHTTP 进入，实际风险很低。

internal/adapter/provider/cliproxyapi_codex/adapter.go (2)

159-184: 流式路径：sseBuffer 在内存中积累全部 SSE 内容。

对于长时间运行或大量输出的流式请求，sseBuffer 会持续增长。当前模式在两个 adapter（codex 和 antigravity）中均相同，属于已知的设计权衡，但建议在后续迭代中考虑对 buffer 大小做上限控制或增量提取 token 指标。

---

229-247: 提取重复的 extractModelFromResponse 和 extractModelFromSSE 到共享的 helper 包。

这两个函数在 internal/adapter/provider/codex/adapter.go、cliproxyapi_codex/adapter.go 和 cliproxyapi_antigravity/adapter.go 中完全重复，其中 extractModelFromResponse 三个文件实现相同，extractModelFromSSE 在 cliproxyapi_codex 和 cliproxyapi_antigravity 中实现相同。建议提取到共享的 helper 包中避免维护多份相同代码。

Go 版本要求已满足：项目 go.mod 指定 Go 1.25，支持 strings.SplitSeq（Go 1.24 引入）。

internal/converter/codex_to_openai.go (2)

364-380: buildOpenAIStreamDone 与 response.completed 分支可能产生不一致的 finish chunk 格式。

buildOpenAIStreamDone（Lines 364-380）使用 Go struct 序列化生成 finish chunk（包含 OpenAIStreamChunk 结构），而 response.completed 分支（Lines 327-339）使用 newOpenAIStreamTemplate + sjson.Set 构建。两种路径产生的 JSON 字段集不同：

• buildOpenAIStreamDone 输出包含 system_fingerprint（omitempty）、usage（omitempty）等字段
• newOpenAIStreamTemplate 输出包含 native_finish_reason、delta 中的 reasoning_content 等字段

下游客户端可能对 finish chunk 的字段一致性有要求。建议统一两个路径的生成方式。

---

145-161: sjson.Set 返回值的错误均被忽略（_）。

整个文件中大量 sjson.Set 调用的 error 被丢弃。sjson.Set 在路径格式不正确时会返回错误。虽然此处使用的路径都是硬编码的字面量，出错概率极低，但作为防御性编码建议，至少在关键路径（如最终输出的 template 构建）记录一下错误。

这是一个可选的改进，不阻塞合并。

internal/converter/openai_to_codex.go (4)

78-82: 变量 c 遮蔽了方法接收者。

Line 81 的 c := m.Get("content") 遮蔽了方法接收者 c *openaiToCodexRequest（虽然在此作用域内接收者未被使用）。建议改用其他变量名（如 contentVal）以提高可读性。

建议修改

-			c := m.Get("content")
-			if c.Exists() && c.Type == gjson.String && c.String() != "" {
+			contentVal := m.Get("content")
+			if contentVal.Exists() && contentVal.Type == gjson.String && contentVal.String() != "" {

后续对 c 的引用也需相应改为 contentVal。

---

24-29: json.Unmarshal 仅用于验证 JSON 合法性，tmp 变量未使用。

Lines 25-28 将 body 反序列化到 interface{} 仅为验证 JSON 格式，然后 Line 29 又 bytes.Clone(body) 直接操作原始字节。虽然功能正确，但可以用 json.Valid(body) 替代以减少不必要的内存分配。

TransformWithState（Lines 252-255）中也有相同模式。

建议修改

-	var tmp interface{}
-	if err := json.Unmarshal(body, &tmp); err != nil {
+	if !json.Valid(body) {
+		return nil, fmt.Errorf("invalid JSON input")
-		return nil, err
 	}

---

459-499: 首次 chunk 处理时重复初始化 state maps。

Lines 468-485 在 !st.Started 分支中重新初始化了 st.MsgTextBuf、st.FuncArgsBuf 等所有 map，但这些 map 刚刚在 Lines 404-414 中已被初始化。这段重复初始化不会造成 bug（仅在首次 chunk 执行），但如果 convertOpenAIChatCompletionsChunkToResponses 被同一 state 对象多次调用（如流式场景），第二次进入时 st.Started 已为 true，不会再重置。

目前逻辑正确，仅作为可读性注记。

---

672-805: finish_reason 处理块超过 130 行，建议拆分子函数。

Lines 672-803 的 finish_reason 处理逻辑包含了消息完成、reasoning 完成、function call 完成和 response.completed 的构建。虽然逻辑正确，但这个单一的 if 块过于庞大，建议拆分为 emitMsgDone、emitFuncCallDone、emitResponseCompleted 等子函数以降低认知复杂度。

internal/adapter/provider/cliproxyapi_antigravity/adapter.go (1)

115-123: updateModelInBody 使用 JSON 反序列化/序列化完整 round-trip 仅为更新一个字段。

json.Unmarshal + json.Marshal round-trip 会重新排列 JSON key 顺序，并可能改变数字精度。考虑到项目已广泛使用 sjson，可以用 sjson.SetBytes(body, "model", model) 替代，保留原始 JSON 结构。

建议修改

+import "github.com/tidwall/sjson"
+
 func updateModelInBody(body []byte, model string) ([]byte, error) {
-	var req map[string]any
-	if err := json.Unmarshal(body, &req); err != nil {
-		return nil, err
-	}
-	req["model"] = model
-	return json.Marshal(req)
+	return sjson.SetBytes(body, "model", model)
 }

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

internal/adapter/provider/cliproxyapi_antigravity/adapter.go (2)

253-283: extractModelFromResponse / extractModelFromSSE 与 codex adapter 完全重复，建议抽取到共享包。

这两个函数在 cliproxyapi_codex/adapter.go（Lines 217-245）中有完全相同的实现。随着更多 CLIProxyAPI adapter 出现（如 Kiro），重复只会增加。建议抽取到如 internal/adapter/provider/cliproxyapi_common 或 internal/usage 等公共位置。

---

245-248: 流式传输中途出错后静默吞没错误 — 建议至少记录日志。

当 streamErr != nil 但已有部分数据写入（sseBuffer.Len() > 0），错误被完全忽略。此时 HTTP 状态码已发送无法回退，但缺少日志会导致排查困难。建议在此处补充一条 warning 级别日志。

🔧 建议修复

+	// If error occurred after partial data was sent, log it for diagnostics
+	if streamErr != nil && sseBuffer.Len() > 0 {
+		log.Printf("[CLIProxyAPI-Antigravity] stream error after partial send: %v", streamErr)
+	}
+
 	// If error occurred before any data was sent, return error to caller
 	if streamErr != nil && sseBuffer.Len() == 0 {
 		return domain.NewProxyErrorWithMessage(streamErr, true, fmt.Sprintf("stream chunk error: %v", streamErr))
 	}

internal/adapter/provider/antigravity/openai_request.go (3)

170-182: 重复的 data URI 解析逻辑可提取为辅助函数。

用户内容（170-182 行）和助手内容（220-232 行）中 data URI 的解析逻辑完全相同。此外，SplitN(…, ";", 2) 后直接取 pieces[1][7:] 假设格式为 <mime>;base64,<data>，但如果 data URI 含有多个参数（如 data:image/png;charset=utf-8;base64,DATA），pieces[1] 将是 "charset=utf-8;base64,DATA"，导致 [7:] 切出错误数据。

建议提取为通用辅助函数并使用 strings.Index(pieces[1], ",") 替代硬编码的 [7:]。

♻️ 建议修复

// parseDataURI extracts MIME type and base64 data from a data URI string.
// Returns mimeType, data, ok.
func parseDataURI(dataURI string) (string, string, bool) {
	if !strings.HasPrefix(dataURI, "data:") {
		return "", "", false
	}
	rest := dataURI[len("data:"):]
	pieces := strings.SplitN(rest, ";", 2)
	if len(pieces) != 2 {
		return "", "", false
	}
	mimeType := pieces[0]
	commaIdx := strings.Index(pieces[1], ",")
	if commaIdx < 0 {
		return "", "", false
	}
	data := pieces[1][commaIdx+1:]
	return mimeType, data, len(data) > 0
}

然后在两处调用：

 						case "image_url":
 							imageURL := item.Get("image_url.url").String()
-							if strings.HasPrefix(imageURL, "data:") {
-								pieces := strings.SplitN(imageURL[len("data:"):], ";", 2)
-								if len(pieces) == 2 && len(pieces[1]) > 7 {
-									mimeType := pieces[0]
-									data := pieces[1][7:]
+							if mimeType, data, ok := parseDataURI(imageURL); ok {
									node, _ = sjson.SetBytes(node, "parts."+itoa(p)+".inlineData.mime_type", mimeType)
									node, _ = sjson.SetBytes(node, "parts."+itoa(p)+".inlineData.data", data)
									node, _ = sjson.SetBytes(node, "parts."+itoa(p)+".thoughtSignature", geminiCLIFunctionThoughtSignature)
									p++
-								}
 							}

Also applies to: 220-232

---

19-25: 整个文件中 sjson.SetBytes 的错误返回值被全部忽略。

虽然 sjson 对合法路径几乎不会出错，但像 line 25 这样 out, _ = sjson.SetBytes(...) 的模式贯穿整个函数（超过 50 处）。如果在构建过程中任何一步意外失败，后续的 set 操作可能在损坏的 JSON 上继续操作，产生难以调试的数据错误。

考虑至少在关键路径（如设置 model、contents、tools 等顶层字段）上检查错误并记录日志。

---

404-404: itoa 可直接使用标准库 strconv.Itoa。

fmt.Sprintf("%d", i) 的性能不如 strconv.Itoa(i)，且此函数在循环中被频繁调用。

♻️ 建议修复

-func itoa(i int) string { return fmt.Sprintf("%d", i) }
+func itoa(i int) string { return strconv.Itoa(i) }

并在 imports 中添加 "strconv"。

internal/converter/openai_to_codex.go (2)

25-29: json.Unmarshal 仅用于验证后丢弃结果，可改用 json.Valid。

Lines 25-28 将 body 解析到 interface{} 仅为验证 JSON 格式，tmp 的值从未使用。json.Valid(body) 更高效，避免了不必要的反射和内存分配。同样的模式也出现在 line 252-254。

♻️ 建议修复

-	var tmp interface{}
-	if err := json.Unmarshal(body, &tmp); err != nil {
+	if !json.Valid(body) {
+		err := json.Unmarshal(body, new(interface{}))
+		return nil, err
+	}

或者更简洁：

-	var tmp interface{}
-	if err := json.Unmarshal(body, &tmp); err != nil {
-		return nil, err
-	}
+	if !json.Valid(body) {
+		return nil, fmt.Errorf("invalid JSON input")
+	}

---

391-395: synthesizeResponseID 使用 fmt.Sprintf 格式化，考虑并发热路径下的性能。

该函数在每个流式请求中被调用。fmt.Sprintf 相比 strconv 系列函数有更高的分配开销。在高并发场景下可以优化：

♻️ 可选优化

+import "strconv"
+
 func synthesizeResponseID() string {
-	return fmt.Sprintf("resp_%x_%d", time.Now().UnixNano(), atomic.AddUint64(&responseIDCounter, 1))
+	return "resp_" + strconv.FormatInt(time.Now().UnixNano(), 16) + "_" + strconv.FormatUint(atomic.AddUint64(&responseIDCounter, 1), 10)
 }

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

internal/adapter/provider/antigravity/openai_request.go (4)

19-25: 全局模式：sjson.SetBytes 返回的 error 均被忽略。

整个函数大量使用 out, _ = sjson.SetBytes(...) 丢弃错误值。对于静态路径来说 sjson 几乎不会出错，因此风险很低。但如果将来路径变得动态化（例如拼接用户输入），静默失败可能导致数据丢失且难以排查。

建议：可以在函数顶部统一声明一个 var setErr error，在关键设置步骤检查并 log，或至少在文档中说明这是有意为之。

---

53-55: 可能遗漏 max_completion_tokens 字段。

OpenAI 较新的 API 使用 max_completion_tokens 替代（或与 max_tokens 并存）。当前仅读取 max_tokens，如果上游客户端使用 max_completion_tokens，则该配置会被静默丢弃。

建议增加回退读取：

🔧 建议修复

-	if maxTok := gjson.GetBytes(rawJSON, "max_tokens"); maxTok.Exists() && maxTok.Type == gjson.Number {
+	maxTok := gjson.GetBytes(rawJSON, "max_tokens")
+	if !maxTok.Exists() || maxTok.Type != gjson.Number {
+		maxTok = gjson.GetBytes(rawJSON, "max_completion_tokens")
+	}
+	if maxTok.Exists() && maxTok.Type == gjson.Number {
 		out, _ = sjson.SetBytes(out, "request.generationConfig.maxOutputTokens", maxTok.Num)
 	}

---

174-176: data URI 解析硬编码了 base64, 前缀长度（7 字符）。

pieces[1][7:] 假设编码方式始终为 base64,。如果遇到非 base64 编码的 data URI（例如 data:text/plain,Hello），这里会错误截取数据内容。

虽然图片几乎都是 base64 编码，但建议改为基于 , 分割以增强健壮性：

🛡️ 建议修复

-							if len(pieces) == 2 && len(pieces[1]) > 7 {
-								mimeType := pieces[0]
-								data := pieces[1][7:]
+							if len(pieces) == 2 {
+								mimeType := pieces[0]
+								commaIdx := strings.IndexByte(pieces[1], ',')
+								if commaIdx < 0 || commaIdx+1 >= len(pieces[1]) {
+									continue
+								}
+								data := pieces[1][commaIdx+1:]

同样的模式出现在 Line 224-226 的 assistant 内容处理中。

---

405-405: 小建议：itoa 可以用 strconv.Itoa 替代 fmt.Sprintf。

strconv.Itoa 相较 fmt.Sprintf("%d", i) 无需格式解析，性能略优且更为惯用。对当前场景影响极小，属于代码风格优化。

internal/converter/openai_to_codex.go (5)

25-29: JSON 验证使用了不必要的反序列化和字节克隆。

json.Unmarshal(body, &tmp) 分配了 tmp 对象仅用于验证 JSON 格式，可以用 json.Valid(body) 替代以避免不必要的内存分配。同时 bytes.Clone(body) 在这里没有必要，因为 gjson.GetBytes 不会修改输入的 body，后续也未对 body 做任何修改操作。

♻️ 建议简化

-	var tmp interface{}
-	if err := json.Unmarshal(body, &tmp); err != nil {
+	if !json.Valid(body) {
-		return nil, err
+		return nil, fmt.Errorf("invalid JSON input")
 	}
-	rawJSON := bytes.Clone(body)
+	rawJSON := body

---

81-81: 局部变量 c 遮蔽了方法接收者。

Line 81 的 c := m.Get("content") 与 Line 24 的方法接收者 c *openaiToCodexRequest 同名，产生变量遮蔽。虽然当前不影响功能（接收者后续未使用），但会降低可读性并增加维护风险。建议重命名为 content 或 cnt。

♻️ 建议修改

-			c := m.Get("content")
-			if c.Exists() && c.Type == gjson.String && c.String() != "" {
+			content := m.Get("content")
+			if content.Exists() && content.Type == gjson.String && content.String() != "" {

后续所有对该变量 c 的引用（lines 82-115）也需相应更新为 content。

---

252-255: 与 Line 25-28 相同的 JSON 验证模式问题。

同上，此处也可用 json.Valid(body) 替代。

---

573-587: Reasoning 状态（ReasoningID/ReasoningBuf）为全局单例，不支持多 choice（n>1）场景。

st.ReasoningID 和 st.ReasoningBuf 在所有 choice 之间共享。若 OpenAI 流式返回多个 choice（n>1），不同 choice 的 reasoning_content 会相互覆盖。当前场景（n=1）无影响，但如需未来扩展支持多 choice，需将 reasoning 状态改为 per-choice（类似 MsgTextBuf map[int]*strings.Builder 的模式）。

---

602-630: 消息完结（finalize message）逻辑在两处重复。

Lines 602-630（tool_calls 到达时关闭当前 message）和 Lines 685-717（finish_reason 到达时关闭所有未完结 message）的事件发射逻辑几乎完全相同（output_text.done → content_part.done → output_item.done）。建议提取为辅助方法（如 emitMessageDone(idx int, ...)）以减少约 50+ 行重复代码。

Also applies to: 685-717